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Disposition of comments on ballot results SC2 N 2994 - 


Summary of Voting on SC2 N2910 - Project 
subdivision for Latin 0 (ISO/IEC 8859-15) 


Attachment 1 — Finland 


We approve with comments the document: SC 2 N 2910 Proposal for Project 
Subdivision on Project JTC 1.20.20 for a new part of ISO/IEC 8859: 8-bit single-byte 
coded graphic character sets -- Part 15: Latin Alphabet No. 0 


"We are prepared to accept the move of the EURO symbol from the currently 
proposed position to e.g. the one occupied in Latin-1 by the international currency 
symbol, if such a move is found acceptable also by other NBs." 


Accepted in principle. Processed in the disposition of comments of the FCD ballot. 


Attachment 2 - Germany 


We have voted the proposal for a new part of ISO/IEC 8859-15 under the number N 
2946. This is also for the document N 2910. 
Comments on ISO/IEC FCD 8859-15 


(1) Germany considers it not necessary to standardise a Latin 0 due to the fact 
that Latin 1, 4, 5 and 6 cover sufficiently the Finnish and French language. 


(2) The EURO symbol is not available on any keyboard and is actually not 
being considered by the software at all. 


(3) Actually the introduction of such a sign is economically not possible to 
realise before the introduction of the EURO. 


(4) It has been laid down in ISO/IEC 646 not to standardise currency signs as 
several misleading interpretations cannot be excluded. Due to this, letters 
are being assigned to currencies e.g. DEN. 


(5) Should this currency sign be requested for electronic business as a 
standardised sign the introduction date of the EURO cannot be guaranteed. \ 
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1. Not accepted. French-speaking countries which are members of JTCI and 
Finland disagree. 


2. Not accepted. Many characters are not available on keyboards and are 
standardized, including characters contained in Latin 1. Further, national and 
international keyboards will cater for the new EURO SIGN as per work 
already undertaken in Europe and in JTC1/WG5S. 


3. Not accepted. The information technology industry has to date already 
expended considerable energy on this issue. 


4. Not accepted. This may be true for banking transactions. It is not true in 
everyday's text applications, for which this standard caters. This is an 
argument against the creation and use of the sign, which is unrealistic, 
whatever the merits of the sign may be. The proposed part of 8859 is an 
implementation in 8 bits of the sign, along with provision of full support for 
French and Finnish, which does fulfill, realistically, a need for such 
implementation. 


5. Not accepted. The EURO SIGN is already required regardless of the 
implementation of the actual currency, and it is economical to standardize it. 


Attachment 3 - Greece 


The Hellenic Standards Body and the National Committee ELOT TE 74 are going to 
propose an alternative way to satisfy the same, as in Latin part, requirement. 


Not accepted. There is no substance in this comment that can be accommodated. 


Attachment 4 - Japan 


The N2910 proposal contains many incompatible changes as well as the new EURO 
character adding. The usage of the proposed Latin-0 character set will cause many 
incompatible changes in systems based on 8859-1. The EURO character will be used 
in wider area and should be available in other character sets in 8859 series. Systems 
based on other Parts of 8859 (than the proposed 8859-15 and 8859-1) have to handle 
Latin-0 character set to represent the EURO character and they will be required much 
incompatible change. JAPAN considers the general currency sign should be used for 
the EURO character. 


Latin 0 (to be renamed Latin 9) does not replace Latin 1. Furthermore, for most 
users, Latin 0 (to be renamed Latin 9) is still highly compatible with existing practice 
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(for example, the text of most web pages written in Latin I will be legible in Latin 9 
and vice versa). Only additional requirements will be fulfilled with this new table, 
without disrupting most current applications. Concerning other parts of 8859, there 
will probably be a requirement for coding the EURO SIGN with the same bit 
combination that will have been chosen in Latin 0 (to be renamed Latin 9). It is likely 
that consensus will assign the EURO SIGN bit combination to be the same as the one 
used for the CURENCY SIGN in Latin 1, as per many countries'comments received 
during the FCD ballot, in line with the last Japanese comment. 


Attachment 5 - Netherlands 


Project subdivision: N 2910 ISO/IEC 8859-15 IT - 8-bit single byte coded graphic 
character sets Part 15: Latin alphabet No. 0 97-11-14, 

DISAPPROVAL WITH COMMENT 

(QI NO, Q2 NO, Q3 NO) 

The NNI votes negative on the Subdivision of Project JTC 1.2.20 for a new part of 
ISO/IEC 8859, Part 15 (SC2 N2910). 

Comments: 

The NNI is aware of the imperfections of ISO 8859-1, and supports inclusion of the 
French LIGATURE OE in a part of 8859, but does not agree to the solution proposed. 


1. Numbering in ISO standards starts with 1, not with 0, thus the 
proposed part should be called Latin Alphabet No. 9. 


2. The code position chosen for the EURO is not acceptable. 


3. The NNI doubts whether extra characters for Finnish are really 
required. In the report "Nordic Cultural Requirements on Information 
Technology" (1992) it is stated in Table 7 (p. 24) that the extra 
characters are in 
class 3, which means: "Letters used in names according to common 
practice, but not part of the language". Furthermore it is stated in Table 
10 (p. 25,26) that 8859-1 satisfies the national requirements of Finland. 
The NNI is fully prepared to consider better solutions for the French 
OE than presented in the proposal, in particular a part of 8859 that also 
satisfies requirements for Turkish. The lack of provision for a language 
spoken in Western Europe by two million people in Germany alone is 
a far bigger problem than that which is attempted to be solved by the 
proposal in SC2 N 2910. 


(1) Accepted. 


(2) Accepted. It will be changed per the comments of other national bodies. 
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(3) Not accepted. The Nordic Requirements handbook is not normative. Finland has 
affirmed its requirement for these characters. Turkish is served adequately by Latin 
5, which we understand to be in use in the Netherlands. 


Attachment 6 - Sweden 


Swedish vote and comments on Proposal for Project Subdivision on Project JTC 
1.2.20 for a new part of ISO/IEC 8859: 8-bit single-byte coded graphic character sets 
- Part 15: Latin Alphabet No. 0 

A. Vote 

Q.1 Do you accept the proposal in document SC 2 N 2910 as a sufficient definition of 
the project subdivision? (If you have responded "NO" to the above questions, you are 
required to comment.) 

Sweden votes YES 

Q.2 Do you support the subdivision? 

Sweden votes YES with the following comments: 

Sweden also sees the need for the Euro character to be covered in other 8859-parts in 
a similar way. Sweden therefore proposes that the possibility to include the Euro in 
some other 8859-parts is studied and that the result of this study may be allowed to 
influence the chosen code position. A Swedish internal document prepared during the 
NB's processing of the matter may be of interest in this connection, and is therefore 
appended as part of the comments. Please find pages 2 - 6 in the enclosed file ag2.pdf. 


Noted. The Swedish document can be discussed in WG3. 


Attachment 8 - USA 


Ballot results for the subdivision of project JTC1.2.20 for the new part ISO/IEC 8859- 
15 

October 31, 1997 

The U.S. does NOT support the subdivision of project JTC1.2.20 for the new part of 
ISO/IEC 8859-15. 

Ql. 

The U.S. believes the project is sufficiently specified. 

Q2. 

The U.S. votes to disapprove the subdivision of project JTC1.2.20 for 8859-15. 

Q3. 

The U.S. will not participate in the development of this new standard. 

Major comments: 

The US disapproves a project subdivision for ISO/IEC 8859-15 for the following 
reasons: 


1) Itis the US long stated position that additional parts of 8859 should not be 
created, except to capture existing 8-bit practice (viz Part 11). Rather than 
addressing problems with particular solutions, which are extremely costly to 
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implement, industry efforts should be focused on implementing a comprehensive 
solutions via the support of ISO/IEC 10646. 


2) From document L2/175 (WG3 N 388) it is clear that the intent is to replace ISO 
8859-1, for the same user community. Because of the prominent role that 8859-1 
has gained as the default character set in many internet protocols, introducing a 
near equivalent standard will have disastrous effects. Due to their large intersection 
part 1 and part 15 would appear to inter-operate without proper adherence to 
announcing mechanisms. Were part 15 accepted and widely implemented, the 
result would be that no-one could be sure that ANY character from the non- 
intersecting part of each set can be used reliably. In many ways, this situation is 
reminiscent of the problems that plagued the 7-bit sets of ISO 646. 


2) The adoption of ISO/IEC 10646 by the vendor community is making rapid 
progress, therefore it cannot be argued that a flawed solution must be accepted for 
lack of practical alternatives. 


3) We do believe that an "EURO SIGN" solution is required in Europe and that the 
US would have enough expertise to lead this project in the right direction and to 
contribute technically. 


1. Not accepted. There are user requirements for this part of 8859 in Europe. 
10646 will not displace 8859 for many years to come. It is to be noted that this 
standard project rectifies existing 8-bit practice with French characters, a 
practice which causes operational problems in interchange because it is not 
standardized. Furthermore, the requirement for the EURO SIGN has been 
expressed sufficiently enough in Europe that it has to be accommodated and 
that 8-bit technology is there to coinhabit with multiple-octet coding long after 
the UCS will have been implemented (most mainframes in the world are still 
using 8-bit technology, this will obtain for a long time to come, and 
interchange between 8-bit technology and the UCS has to be done in a 
standard way, a standard way which would otherwise be missing for integral 
French (this is currently recognized in ISO/IEC 8859 tables which only partly 
support French), integral Finnish, and support of the EURO SIGN). 


2. Not accepted. Protocols for identification of code tables in e.g. HTML or mail 
protocols exist and can be used to identify whether something was written in 
Latin I or Latin 5 or Latin 9. If those protocols are used then the stated 
problem does not exist. It is a simple question of the will to implement. Those 
who do not have the requirement for EURO SIGN, or French and Finnish 
characters, will not see any difference indeed with the new characters if it is 
not properly tagged and assumed to be Latin I. Those who have the need will 
not suffer as characters replaced are near to being unsignificant or irrelevant 
in actual applications. That said, the standard specifies that agreement must 
exist between sender and recipient for identifying the character set. This will 
either be done implicitly or by proper tagging. This is not more problematic 
than deciding between the different versions of the UCS (pre-amendment 5, 2 
octet, 4 octet, UTF-8 or UTF-16). Furthermore care has been taken not to 
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modify Latin 1 itself, but to create a new table, to avoid repeating the pre- 
amendment-5 UCS obsolescence problem (that is to say, this solution was 
arrived at after consideration and rejection of the idea of modifying Latin 1 
itself, creating instead a new code table. We note that some companies have 
already undertaken to support 8859-15 in their implementations as no other 
solutions have been put forward. 


3. Not accepted. "Rapid progress" is not seen to be rapid enough. Requirement 
for 8-bit support will not go away just because the vendor community is 
"making rapid progress". Neither is the adoption of the UCS by the vendor 
community equivalent to the obsolescence of the 8-bit world or the end of its 
development (for instance, Windows 98 will externally still be 8-bit, with even 
modifications relatively to the Windows 95 native character set, namely for the 
EURO SIGN and Finnish characters: Latin 9 will allow standard interchange 
of those additions. As another example, IBM will have to modify its CECP 
EBCDIC code tables for the EURO SIGN, as well as the code page 850; the 
lack of a standard interchange between all those development outcomes would 
mean a missing link with the UCS and between these environments). In fact 
standardizing Latin 9 serves the vendor community as well as user 
requirements. 


4. Noted. 


